By David Long, Vitech President
“The biggest errors are made on day one.” Sadly, those involved in systems engineering live this every day, but not necessarily in the manner we think. Though we strive to avoid this pitfall and address it in the systems we develop, the very way we approach our practice is often flawed. We break systems engineering from day one by our flawed practices, many times not even recognizing that we have done so.
In talks and tutorials, I frequently ask how many in the audience are applying a waterfall process. The general response is a hand or two timidly raised with the rest of the audience proudly asserting that they execute a spiral, incremental, or agile process – anything but waterfall. I then ask an individual “If I wanted to know about your requirements, who would I talk to?”
“That would be Courtney’s group on the second floor,” comes the response. “Great, and if I wanted to understand your architecture?” “You would need to talk with Nicole’s team on the fourth floor.” “And for test?” “Oh, that would be Fred’s group over in building 12.” The waterfall process itself has merit for certain classes of problems under certain conditions (e.g., high assurance systems in an environment defined by stability in requirements and technology). However, the resultant stovepiping evils it embeds in our organizations have no place. Regrettably, even where the waterfall approach has been avoided in the surface processes, those stovepiping evils have been retained and even embraced.
The systems engineering profession purportedly founded on holism, seeing the big picture, emergence, and the value of connection quickly reverts to reductionism, breaking itself into pieces. The paradox of our behavior is that although we profess holism, we structure our organizations and our processes around reductionism – artificially separating our teams, segregating our data, and partitioning our processes. And that is the biggest error we can make.
As Stanley McChrystal asserts in Team of Teams, “Attempts to control complex systems by using the kind of mechanical reductionist thinking … breaking everything down into component parts, or optimizing individual elements … tend to be pointless at best or destructive at worst.” We know this to be true for the electromechanical and cyber-physical systems we develop. Systems engineers – and the organizations that employ them – ostensibly embrace holism as we apply our principles to products. But when we look at ourselves – our organizations and our practice – we suddenly become blind to those same systems principles. The enterprises and the humans that comprise them are far more complex than the products we build, yet we revert to reductionist approaches rather than the holism necessary for success.
Metcalfe’s Law states that the value of a telecommunications network is proportional to the square of the number of connected users of the system. This is true in any communications structure. Rather than rejecting connection by subdividing systems engineering – the mindset, the processes, the supporting data, and the teams that practice it – we should seek to create and embrace connections, emphasizing coordination and trust over reductionism and separation.
Unfortunately, it is beyond the power of most systems engineers to completely heal the fractures that plague us. Some are embedded in our corporate structure and culture. Some are embedded in acquisition and development processes. We may not be empowered to reengineer our organizations or the processes we execute, but we can still help address the problem. There are three simple things that every systems engineer can do.
Think horizontally
As the old maxim states, “Working with requirements is like walking on water – it’s easier when everything is frozen.” Though amusing and appealing in concept, this ignores the interdependencies in our systems engineering efforts, the reality of change in our environments and technologies, and the very nature of complex problems. So if the connections and interrelationships are key, don’t look vertically and hope to stovepipe the concerns. This is akin to living as an ostrich with your head in the sand, blind to the world around you. Instead, always choose to think horizontally and embrace the interdependencies.
Systems engineering was conceived as a concurrent activity – not simply concurrent between the disciplines engaged in engineering the system, but concurrent across the concerns as well. It’s easy to see that changing a requirement can have a ripple effect through a system design that impacts behavior, architecture, and test. Likewise, changing a component selection during the design process can have a ripple effect outward potentially impacting the allocation of behavior, the behavior itself, test considerations, and lower-level requirements. Recognize this, and even if your structure or process forces you to focus vertically, think horizontally to see and appreciate the connections.
At a conceptual level, the “partitions” of systems engineering – from operational concept through statement of need to behavior, architecture, test, programmatics, and beyond – are simply viewpoints. Requirements are a problem-oriented viewpoint on a system. Behavior looks at that same system through a logical lens. Architecture does so from a physical viewpoint. The objective is not separation of concerns. The objective is congruence in the viewpoints, harmony and elegance in understanding of the problem and the resulting solution. That elegance does not come from reductionism and thinking vertically. It comes from holism, thinking horizontally, and embracing interconnectedness: of requirements and architecture, of enterprise and product, of process and data, and of all things in engineering the system of interest.
Serve as the humble connector
A systems engineer in isolation has little value. A systems engineer teamed with the right blend of people to understand the problem and the necessary subject matter experts to deliver the solution is a thing of beauty. While the systems engineer may or may not lead, the systems engineer should always serve as the humble connector. Aware of the power of emergence in systems, we must be the technical connective tissue between specialists taught to see in reductionist terms.
As computer scientist Sandy Pentland found, “The collective intelligence of groups and communities has little to do with the intelligence of individual members and much more to do with the connections between them.” It’s about sharing information and strong horizontal relationships. The connections create emergence. If emergence is critical to the systems we build, we should also recognize the importance of emergence in our enterprises.
But the manner in which we connect is key. Tocqueville said, “Empowerment without context will lead to havoc.” Likewise, specialists performing specialized work without seeing the big picture, without understanding how their part fits into the whole, without understanding their impact on others will lead to havoc in the processes and the result. At a minimum, the systems engineer must reach across disciplines and even organizational boundaries to communicate the bigger picture, highlight the dependencies, and raise both individual and collective awareness. Done well, that humble connector function creates shared understanding and increases interactions. In doing so, the systems engineer can overcome structural and cultural divisions to align diverse perspectives, share knowledge, unlock creativity born from collaboration within shared context, and achieve extraordinary solutions.
Reawaken the systems perspective in others
While the humble connector may communicate the big picture, we can go a step further. In addressing fractures, we can help specialists rediscover and reawaken their systems perspective.
We are all born with a systems perspective. When a child asks why, they are often trying to see and understand the interrelationships around them – not necessarily the big picture that we speak of, but certainly how pieces, information, and phenomena fit together. While we may be born with that gift, western education in its quest to develop ever-deeper specialists in ever-narrower fields trains most people to ignore their innate systems perspective.
The specialization that western education creates has been responsible for tremendous advances. Reconnecting reductionist thinking with systems thinking and systems awareness is even more powerful as individuals leverage their deep knowledge in context while being conscious of greater considerations and impact. By helping others seek out and appreciate the value of interconnections across systems and across disciplines, we begin to reawaken their systems perspective. Rather than serving as their holistic voice, we help them to see the big picture and the interdependencies themselves. Doing so is akin to developing new pathways in a neural network. Reawakened individuals may retain a discipline focus, but they become additional connective tissue, helping to bridge fractures in organization and in process.
If complexity is defined by interactions, how can we as systems engineers choose to ignore those interactions ourselves? Completely transforming our enterprise, culture, and processes may be beyond our reach. But returning to our first principles and applying the systems mindset to our practice and profession is not. Thinking horizontally, serving as a humble connector, and reawakening the systems perspective in others may not fully heal an organization or process defined by reductionist thinking, but it can certainly bind the fractures enabling the team to deliver greater results.
